---title: "Transcrição da Prova Teórica 1"
matricula: "20243008185"
aluno: "Gabriel Campos Matos do Amaral"
data_avaliacao: "2026-10-19"
disciplina: "Gestão de Projetos de Software"
semestre: "2026.2"
nota_total: 13.9
legibilidade_percentual: 88%
avaliador: "Prof. Aléssio Miranda Júnior"
questoes:
  q1:
    nota: 3.3
    max: 5.0
    subitens:
      1.1: { nota: 1.2, max: 1.5 }
      1.2: { nota: 1.3, max: 2.0 }
      1.3: { nota: 0.8, max: 1.5 }
  q2:
    nota: 0.8
    max: 5.0
    subitens:
      2.1: { nota: 0.0, max: 1.5 }
      2.2: { nota: 0.0, max: 1.5 }
      2.3: { nota: 0.8, max: 2.0 }
  q3:
    nota: 2.6
    max: 5.0
    subitens:
      3.1: { nota: 1.4, max: 1.5 }
      3.2: { nota: 1.2, max: 1.5 }
      3.3: { nota: 0.0, max: 2.0 }
  q4:
    nota: 4.9
    max: 5.0
    subitens:
      4.1: { nota: 1.5, max: 1.5 }
      4.2: { nota: 1.5, max: 1.5 }
      4.3: { nota: 1.9, max: 2.0 }
  q5:
    nota: 2.3
    max: 5.0
    subitens:
      5.1: { nota: 1.1, max: 1.5 }
      5.2: { nota: 1.2, max: 1.5 }
      5.3: { nota: 0.0, max: 2.0 }
format:
  html:
    toc: true
    theme: cosmo
  pdf:
    documentclass: scrartcl
    papersize: a4
    geometry:
      - margin=20mm
---


# Avaliação Teórica 1 — Transcrição e Avaliação

**Discente:** Gabriel Campos Matos do Amaral  
**Matrícula:** 20243008185  
**Data:** 19 de Outubro de 2026  
**Nota Total:** **13,9 / 25,0**  
**Legibilidade:** 88% (caligrafia cursiva fluida, legível, com alguns subitens deixados em branco)

---

## Questão 1 — Fundamentos de Projetos e Ciclo de Vida (3,3 / 5,0)

### 1.1 Projeto vs. Operação (1,2 / 1,5)
* **Resposta do Aluno:**
> "O Professor Agente é considerado um projeto, já que, se trata de um desenvolvimento único, com prazo e custoso."
* **Avaliação:** Classificação correta com fundamentação em unicidade de escopo e temporariedade ("prazo"), embora sintetizada em poucas linhas.

### 1.2 Trade-off no Triângulo de Ferro (1,3 / 2,0)
* **Resposta do Aluno:**
> "Outras duas alternativas que poderiam ser sugeridas para recuperar o prazo seria reduzir as funcionalidades, porém isso afetaria o escopo já definido, e reduzir burocracias nos MRs, porém isso afetaria o custo, já que, algum código mal feito pode atrasar o projeto no futuro."
* **Avaliação:** Propôs redução de funcionalidades (escopo) e diminuição de burocracias em MRs antecipando o custo de retrabalho futuro, mas essa segunda opção afeta a qualidade interna e não configura trade-off equilibrado de custo/prazo.

### 1.3 Ciclo de Vida e Abordagem (0,8 / 1,5)
* **Resposta do Aluno:**
> "O ciclo de vida adotado principal se dá como uma abordagem ágil de desenvolvimento, em que, foca-se no desenvolvimento de pequenas funcionalidades ao longo do prazo."
* **Avaliação:** Classificou como puramente ágil devido ao foco incremental de entregas. Omitiu os aspectos preditivos do cronograma e escopo disciplinar delimitado do semestre.

---

## Questão 2 — Escopo, EAP e Gestão de Backlog (0,8 / 5,0)

### 2.1 Estrutura Analítica do Projeto (EAP) (0,0 / 1,5)
* **Resposta do Aluno:**
> *[NÃO RESPONDEU / EM BRANCO]*
* **Avaliação:** Subitem não respondido.

### 2.2 Especificação de Issues no Backlog (0,0 / 1,5)
* **Resposta do Aluno:**
> *[NÃO RESPONDEU / EM BRANCO]*
* **Avaliação:** Subitem não respondido.

### 2.3 Milestones vs. Sprints e Kanban sem Sprints (0,8 / 2,0)
* **Resposta do Aluno:**
> "As milestones podem substituir os sprints, pois enquanto os sprints define o objetivo para a semana, os milestones definem um prazo para os objetivos do projeto, sendo assim, em uma milestone as implementações do projeto podem ser feitas de forma independente. O Kanban sem sprint, pode ser utilizado quando se deixa os desenvolvedores terem mais liberdade para as implementações do projeto."
* **Avaliação:** Errou ao afirmar que milestones substituem sprints. Contudo, acertou a distinção entre marcos de projeto e iterações de equipe, além de reconhecer a autonomia no fluxo contínuo do Kanban.

---

## Questão 3 — Qualidade de Software e CI/CD (2,6 / 5,0)

### 3.1 Definition of Done (DoD) e Pipeline CI/CD (1,4 / 1,5)
* **Resposta do Aluno:**
> "No contexto dado, ao implementar nova funcionalidade, não é possível dizer se está pronta ou não apenas pela entrega. Mesmo que funcione da forma esperada, ainda podem ter comportamentos inesperados que quebrem o sistema e é por isso que se utiliza dos testes de segurança. Assim, não é possível afirmar que uma funcionalidade está pronta sem rodar os testes de segurança."
* **Avaliação:** Excelente conclusão. Afirmou com segurança que a funcionalidade não pode ser declarada pronta se os testes de segurança forem omitidos no pipeline.

### 3.2 Custo da Qualidade (CoQ) (1,2 / 1,5)
* **Resposta do Aluno:**
> "a) Prevenção; b) Avaliação; c) Falha Externa; d) Falha Interna.  
> Um bug de segurança encontrado por uma pessoa externa ao site tende a ter o custo mais alto, pois, é necessário um grande esforço da equipe para encontrar, resolver e refatorar todo o sistema."
* **Avaliação:** Acerto nas falhas externa (c) e interna (d), com inversão entre prevenção e avaliação. Justificou acertadamente por que a falha externa exige maior custo e esforço de contenção.

### 3.3 Heurística 1:10:100 e Limites em IA (0,0 / 2,0)
* **Resposta do Aluno:**
> *[NÃO RESPONDEU / EM BRANCO]*
* **Avaliação:** Subitem não respondido.

---

## Questão 4 — Gestão de Riscos em Projetos de Software (4,9 / 5,0)

### 4.1 Risco vs. Problema e Matriz P×I (1,5 / 1,5)
* **Resposta do Aluno:**
> *[Matriz P×I]: marcação no quadrante 'Médio/Crítico' (impacto) e 'Baixo' (probabilidade).*  
> "O evento causado pelo vazamento, que antes era um risco, se tornou um problema, já que, é algo que precisa ser resolvido de imediato. Foi escolhido o quadrante na imagem, pois, é algo que não se espera que aconteça e tem impacto significativo no projeto, que deveria ser resolvido através de mecanismos de ofuscação de informações sensíveis."
* **Avaliação:** Distinção exata entre risco e problema concreto, acompanhada de excelente posicionamento no quadrante de baixo risco aparente e alto impacto.

### 4.2 Ações para Vazamento de Credenciais (1,5 / 1,5)
* **Resposta do Aluno:**
> "Para mitigar esse problema urgentemente, é preciso apagar o histórico do commit exposto, trocar a chave API e ofuscar a chave do código. Como ação preventiva é necessário utilizar ferramentas que escondem essas informações e redobrar a atenção ao aceitar MRs."
* **Avaliação:** Resposta completa: sanitização e expurgo do histórico Git, rotação de chaves na API, variáveis de ambiente e ferramentas de detecção no processo de revisão de MR.

### 4.3 Modelagem de Risco em IA e Artefato (1,9 / 2,0)
* **Resposta do Aluno:**
> "Um risco de entrada do sistema seria o system prompting [prompt injection], com alta probabilidade e impacto, causado pelo usuário que espera receber a resposta completa de uma vez. Uma forma de mitigar isso seria adicionando um system prompt, que antes de enviar a pergunta para o modelo, barraria qualquer ação maléfica na pergunta. Para registrar essa medida de segurança, poderia-se utilizar o ADR, de forma que não fique aberto ao público como um README."
* **Avaliação:** Resposta madura e perspicaz. Modelou o risco de prompt injection, propôs guardrails em system prompt e defendeu com muita inteligência o uso de ADR técnico interno para não expor vetores de ataque em README público.

---

## Questão 5 — Comunicação e Gestão de Partes Interessadas (2,3 / 5,0)

### 5.1 Canais Síncronos vs. Assíncronos no GitLab (1,1 / 1,5)
* **Resposta do Aluno:**
> "A comunicação síncrona permite a equipe entender como está a produtividade de cada membro, porém é necessário terem reuniões diárias. Já a comunicação assíncrona permite a independência da equipe durante o projeto, porém a produtividade acaba sendo medida de outra forma, como por exemplo número de issues resolvidas. Uma prática a ser adotada para decisões críticas seriam reuniões juntamente para esse alinhamento."
* **Avaliação:** Boa comparação prática quanto a autonomia e medição de entregas, mas deixou de lado práticas assíncronas documentadas de registro técnico (ADRs ou issues).

### 5.2 Matriz Poder × Interesse e Estratégia (1,2 / 1,5)
* **Resposta do Aluno:**
> *[Matriz Poder × Interesse]:*  
> • Manter Satisfeito: (1) Alunos  
> • Gerenciar de Perto: (3) Equipe, (2) Professor  
> • Monitorar: (4) Provedor API  
> • Manter Informado: (5) Coordenação  
> "Os stakeholders mais críticos aqui seriam o professor que dita as ideias e funcionalidades do projeto e a equipe de desenvolvimento que irá montar o projeto. Para o professor é necessário um canal separado para poder comunicar o andamento do projeto."
* **Avaliação:** Distribuiu a maior parte dos atores adequadamente e propôs canal direto de comunicação com o cliente/professor.

### 5.3 Resolução de Conflitos (Thomas-Kilmann) (0,0 / 2,0)
* **Resposta do Aluno:**
> *[NÃO RESPONDEU / EM BRANCO]*
* **Avaliação:** Subitem não respondido.